The invention relates generally to automatic test equipment, and more particularly to techniques for controlling such equipment.
In general, automatic test equipment (ATE) is equipment for testing devices (or complete systems) in an automated manner. Some ATE systems test electronic circuitry such as integrated circuits (ICs) or circuit boards. When a typical ATE system tests such a device (commonly referred to as the device under test or DUT), the ATE system applies stimuli (e.g., electrical signals) to the device and checks responses (e.g., currents and voltages) of the device. Typically, the end result of a test is either xe2x80x9cpassxe2x80x9d if the device successfully provides certain expected responses within pre-established tolerances, or xe2x80x9cfailxe2x80x9d if the device does not provide the expected responses within the pre-established tolerances. More sophisticated ATE systems are capable of evaluating a failed device to potentially determine one or more causes of the failure.
It is common for an ATE system to include a computer that directs the operation of the ATE system. Typically, the computer runs one or more specialized software programs to provide (i) a test development environment and (ii) a device testing environment. In the test development environment, a user typically creates a test program, i.e., a software-based construct of one or more files that controls various portions of the ATE system. In the device testing environment, the user typically provides the ATE system with one or more devices for testing, and directs the ATE system to test each device in accordance with the test program. The user can test additional devices by simply providing the additional devices to the ATE system, and directing the ATE system to test the additional devices in accordance with the test program. Accordingly, the ATE system enables the user to test many devices in a consistent and automated manner based on the test program.
In general, there are two conventional approaches to creating a test program using the test development environment of the ATE system: a code-based approach and a template-based approach. In the code-based approach, the user writes code in a programming language (e.g., the C or C++ programming languages) with extensions and libraries. In general, the code controls low-level operations of various components within the ATE system such as voltage and current sources, measuring devices, and data storage resources. Additionally, if multiple devices are to be tested in parallel, specific code must usually be added to control the additional ATE system components which are required to test the additional devices, substantially increasing program complexity. Accordingly, the code-based approach generally requires the user to posses extensive knowledge of a programming language and the various components of the ATE system. Typically, the developed code is several thousand lines long, and often requires significant time and effort to test and debug before formal device testing can begin.
The code-based approach is powerful and flexible because it allows the user to utilize the resources of the ATE system to their fullest potential. Since the user essentially develops the test program from scratch by writing the code, the user can customize and tailor the test program to take full advantage of the ATE system. For example, the user may include certain optimizations in the test program to operate the ATE system in a manner that provides the quickest test times attainable and thus maximize the capacity of the ATE system. Additionally, the user is not bound to industry testing methods or standards. Rather, the user has the capability to establish and implement user-specific testing methods and standards which, in some respects, may be superior to industry norms. Moreover, the user can test as many different types of devices as appropriate for the ATE system""s capabilities. This is particularly important with regard to testing mixed-signal devices which utilize both analog and digital signals, and where device-specific configuration is typically required before devices are ready to accept stimulus signals and provide response signals.
In contrast to the code-based approach, the template-based approach is less burdensome on the user. In the template-based approach, the ATE system manufacturer supplies the user with a selection of test program templates. Each template typically includes code prewritten by the ATE manufacturer thus alleviating the need for the user to write code from scratch. Furthermore, such a template is generally customizable to a degree. For example, a particular test program template may allow the user to enter certain operating parameters that control particular actions performed by the ATE system when testing a device. It is also typical that a test program template can apply the customized operating parameters to multiple devices in parallel and make measurements from multiple devices in parallel. More extensive changes typically require the user to examine and edit the prewritten code if the ATE makes this underlying code accessible to the user. Accordingly, in the template-based approach, the task of the user is to select a template that is well-suited for the particular intended test, and to provide suitable operating parameters to the selected template in order to direct the ATE system to properly perform the intended test.
In general, from the perspective of the user, the template-based approach is relatively easier to use than the code-based approach. In the template-based approach, the user takes advantage of prewritten test programs thus avoiding having to write code from scratch. Accordingly, the user does not require extensive knowledge of a programming language or low-level details of the ATE system. Rather, the user simply selects a prewritten template and sets particular operating parameters for the selected template to customize the operation of the ATE system. As such, the user essentially plays the role of an ATE operator rather than a test program developer.
Unfortunately, the code-based and template-based approaches to creating a test program have certain drawbacks. In particular, the code-based approach, in which a user writes a test program from scratch, requires the user to posses extensive knowledge of a programming language and low-level details of the various components of the ATE system. Without such knowledge the user would not be able to create a test program that properly operates the various portions of the ATE system to test a device. Furthermore, even with such knowledge, the task of creating the test program is complex and error-prone. Typically, the user invests a significant amount of time developing and debugging a test program before the test program is ready for regular use in device testing.
The template-based approach, in which a user utilizes prewritten test program templates provided by the ATE manufacturer, suffers from certain drawbacks as well. First, this approach is relatively inflexible because the user can only choose from test program templates that the ATE manufacturer has conceived in advance. Such templates often cannot be customized to the extent necessary to test devices which have complex device-specific configuration requirements, such as mixed-signal devices.
Second, some ATE users prefer to establish and implement their own user-specific methods and standards rather than rely on those provided by the ATE manufacturer. In some situations, it is difficult or impossible for such users to implement their own methods and standards by modifying prewritten templates since these templates typically only accept operating parameter changes. More extensive modifications usually entail working at a lower level by searching and editing the underlying template instructions, and verifying that no undesired changes have been made. Modifying and debugging such code can, on occasion, be a more difficult task than writing code from scratch.
Third, as ATE manufacturers attempt to increase the flexibility and customizability of their templates, the templates tend to become more complex from the perspective of the user. In some situations, creating a test program by developing a proficiency in a prewritten template and then modifying that template may be a larger burden on the ATE user, than just writing a test program from scratch. In particular, the user may already possess some knowledge of a programming language and the components of the ATE system. Such a user would now have the burden of having to further learn the details of the manufacturer""s test program template and then determine how to modify it.
To avoid making test program templates too complex, ATE manufacturers may attempt to provide a wider selection of test program templates. Unfortunately, this becomes extremely burdensome on the ATE manufacturer, and it is often impossible for the manufacturer to anticipate and satisfy every need of the ATE system user with a test program template. For example, it is unrealistic to expect an ATE manufacturer to provide a separate template for every possible mixed-signal test arrangement (a device test which involves both analog and digital signals) due to the large number of different signal combinations. The manufacturer would likely not be able to complete such an undertaking in a timely manner. Moreover, the ATE system user likely would be overwhelmed by the selection of test program templates, and perhaps may not choose the best-suited test program template for a particular situation. Nevertheless, if the ATE manufacturer does not provide a template which is well-suited for a desired device test (e.g., one that is capable of handling the correct number of analog and digital signals of the intended device under test), the ATE user likely will be unable to effectively test the devices unless the user modifies a less-suitable template. Often such modifications require extensive code changes.
In contrast to the above-described conventional code-based and template-based approaches to creating a test program, the invention is directed to techniques for providing a test procedure from multiple test elements. Each test element defines instructions and programmable input variables for a particular test operation. Preferably, each test element embodies the basic functionality of one of the ATE system""s instruments or capabilities. The test procedure defines a device testing task and can operate as a test program, or be combined with other test procedures (or one or more instances of the same test procedure) to form a larger test program. Accordingly, the there is no need to write a test program code from scratch as in the conventional code-based approach. Furthermore, providing a test procedure from test elements generally provides greater flexibility than modifying prewritten test program templates since individual test operations defined by the test elements can be combined in a customized fashion to suit the particular needs of the ATE user.
In one arrangement, the ATE user combines multiple test elements from a test element database to form a test procedure which defines a device testing task. Each test element defines instructions and programmable input variables that direct a processor to perform a particular test operation of the device testing task. The ATE user sets at least a portion of the programmable input variables of each test element forming the test procedure to initial values. Additionally, the ATE user indicates an operating order for the test elements forming the test procedure. Furthermore, the ATE user stores the test procedure within a memory. Accordingly, the ATE user can create a customized test program suitable for testing a specific device such as an IC or a circuit board. Furthermore, the ATE user is not burdened with writing code from scratch and does not need to possess extensive knowledge of a programming language or low-level details of the ATE components as is necessary in the code-based approach.
Additionally, the ATE user has the capability to nest the test procedure within another test procedure. Such a nesting feature enables the ATE user to better organize the test program through modularization. Moreover, the ATE user may be able to reuse certain test procedures on other types of devices that are similar to the device for which the test procedure was originally created.
Preferably, the test element database includes analog signal test elements which define instructions that direct the processor to perform analog signal test operations, digital signal test elements which define instructions that direct the processor to perform digital signal test operations, and other test elements which define instructions for configuring the DUT to receive and transmit stimulus and response signals. The task of combining these analog signal test elements, digital signal test elements, and DUT configuration test elements to form a mixed-signal test procedure or test program is, in many respects, easier than trying to convert a mixed-signal template designed to handle a particular set of signals and DUT configuration requirements, as is sometimes necessary in the conventional template-based approach to effectively test a mixed-signal device.
After the ATE user creates a test procedure from test elements, an ATE system can use the test procedure to test a device. In particular, when the user begins a formal device test, the user enters commands on an input/output (I/O) device of the ATE system to begin a test. In response, a processor of the ATE system obtains the test procedure from memory, and provides a series of instructions based on the test procedure. In response, the processor controls a test interface, which connects (e.g., electrically or mechanically) with the device under test, based on the provided series of instructions in order to test the device.
Preferably, the ATE system provides a graphical user interface (GUI) through the I/O device. The user operates the GUI to create the test procedure from test elements of the test element database. In particular, the user preferably selects graphical icons corresponding to respective test elements, and arranges the icons in an editor window of the GUI to provide an operating order for the test elements. Additionally, the user sets programmable input variables of the test elements to initial values using dialog boxes which vary depending on the operation defined by the test element. The underlying instructions for the test operations which define the test elements is preferably prewritten by the ATE manufacture so that the user can simply manipulate icons and enter parameter values. Hence, the user has the power and flexibility of the code-based approach since the user creates a test program (or test procedure) from scratch, but is does not require extensive knowledge of a programming language or low-level details of ATE components since the user is not writing lines of code from scratch.
It should be understood that the test elements of the test procedure are preferably arranged so that information resulting from one test element of the test procedure can be used by another test element. That is, when the ATE system operates in accordance with the test procedure during a device test, the test operation results from one test element are used by the other test element. For example, one test element can direct the ATE to take measurements from a device under test. A subsequent test element can process these measurements to determine whether the device operates properly.
It should be further understood that the processor preferably includes multiple processing units that are associated with respective multiple devices. In this arrangement, controlling the test interface involves operating each of the multiple processing units based on the provided series of instructions to test each of the respective multiple devices in parallel. This arrangement enables the ATE system to be scaled by increasing the number of processing units within the processor. It should be farther understood that preferably a test procedure and its test elements automatically test as many devices in parallel as are presented to the test interface, in contrast to a conventional code-based test program which normally requires significant modification in order to test different numbers of devices in parallel.
Another arrangement of the invention is directed to a computer program product that includes a computer readable medium having instructions stored thereon for performing the above-described test procedure. The instructions, when processed by a data processing device, cause the data processing device to combine test elements from a test element database to form the test procedure in response to user commands such that the test procedure (i) defines a device testing task, and (ii) includes multiple test elements. The instructions further cause the data processing device to (i) set at least a portion of the programmable input variables of each test element forming the test procedure to initial values, (ii) indicate an operating order for the test elements forming the test procedure, and (iii) store the test procedure within a memory, in response to further user commands.
Another arrangement of the invention is directed to a computer program product that includes a computer readable medium having instructions stored thereon for testing a device. The instructions, when processed by a data processing device, cause the data processing device to obtain a test procedure which defines a device testing task. The test procedure includes multiple test elements defining instructions and programmable input variables that direct the processor to perform particular test operations of the device testing task. The instructions further cause the data processing device to provide a series of instructions based on the test procedure, and control the test interface based on the provided series of instructions in order to test the device.
The features of the invention, as described above, may be employed in an automatic test system and other related devices such as those manufactured by Teradyne, Inc. of Boston, Mass.